The New MCP Authorization Specification

Amongst all of the news that is filling the AI airwaves, you might’ve missed that yesterday, in collaboration with our friends at Anthropic, we’ve published a brand-new authorization specification for Model Context Protocol (MCP).

This has been a collaborative effort that was originally tracked in a pull request in the modelcontextprotocol/modelcontextprotocol repository. You might also remember me asking you to provide feedback on it just a bit more than two weeks ago. This was a massive collaboration with folks at Microsoft, Okta/Auth0, Arcade.dev, Hellō, Stytch, Descope, and many, MANY, more.

The spec underwent some changes and trimming to improve clarity, and a new version has been rolled from another pull request.

What does the spec introduce #

One of the biggest changes that you might notice is the clean separation between the MCP server being a Resource Provider (RP) and Authorization Server (AS). The previous version of the specification assumed that both were colocated; however, in practice that would mean that developers would need to write their own Authorization Server to get things up and running.

This is tricky to get right, but also - there are third-party AS solutions out there that can be integrated with MCP servers relatively easily. Why have developers do more work?

The new specification brings quite a bit of clarity in this domain. Every MCP server will now need to host a Protected Resource Metadata (PRM) document (by the way, the RFC9728 was just officially assigned to this document - congrats to Aaron Parecki).

What this means in practice is that every MCP server will now be able to provide this document in a well-known location:

{
  "resource": "https://resource.example.com",
  "authorization_servers": [
    "https://as1.example.com",
    "https://as2.example.net"
  ],
  "bearer_methods_supported": [
    "header",
    "body"
  ],
  "scopes_supported": [
    "profile",
    "email",
    "phone"
  ],
  "resource_documentation": "https://resource.example.com/resource_documentation.html"
}

The MCP client will be able to discover this document and then use the declared authorization server (can be anything - Entra ID, Okta, Auth0, or a myriad of others) to kickstart the authorization code flow with Proof Key for Code Exchange (PKCE).

And the discovery step is delightfully straightforward - when the client first talks to the MCP server, it will receive a HTTP 401 Unauthorized response with a WWW-Authenticate header, that contains a resource_metadata field that points directly to the PRM document. From there, the client can extract the AS and initiate the authorization dance.

So no more writing custom token services? I can just delegate everything to the authorization server and not worry about the complexity of token management?

Almost! You will still need to ensure that the AS supports Dynamic Client Registration (DCR) and if it doesn’t, either have the client provide a way to specify pre-registered client ID, or have the MCP server act as the registering authority (although at that point you partially implement the AS in your MCP server, at least for the /register endpoint).

Overall, though, it’s a massive step that simplifies how authorization can be implemented in MCP server scenarios.

What’s next? #

There are a few incremental changes that we’re still working through as fast-follows to the specification, most of them related to security best practices. This will help MCP server developers make sure that they’re not doing anything that can put their customers and their data at risk.

In the meantime, I am also working through implementing authorization in the MCP C# SDK. It might take me a few days to get this in a reviewable shape, but it’s on the way and I am excited to get this in the developers’ hands for testing.

I am sure other SDKs and clients will soon follow.

Acknowledgements #

As I mentioned above, there are a LOT of people that contributed with their feedback and input to the specification. But I would specifically like to call out the following folks, who provided extremely helpful comments and helped shape the spec into what it is (in no particular order):

David Soria Parra, Aaron Parecki, Diana Smetters, Caitie McCaffrey, William Bartlett, Pieter Kasselman, ciamshrek, Max Gerber, Allen Zhou, Jeff Lombardo, Adrian Frei, Dasith Wijesiriwardena, Xiao Yijun, Nate Barbettini, Matthew Henderson, Tolga Acar, Karl McGuinness, Barry Dorrans, Dick Hardt, Annaji Sharma Ganti, Stephen Halter, Hirsch Singhal, Wils Dawson, Tyler James Leonhardt, Henry Mao, Cliff Hall, Brendan Irvine-Broque, Justin Spahr-Summers, Darin McAdams

I am sure there are more that I am forgetting, so if I missed you, let me know in the comments. I appreciate collaborating with every single one of you.

And as always, I am happy to talk about identity or security topics, so if you see me in the Anthropic or any of the working group Discord chats, drop me a message!